Much
of the configuration that is done for the Mailbox server role is done
during the hardware configuration and installation of the Mailbox role.
After the Mailbox role is installed, creating and configuring databases
usually completes most of what needs to be done. After the deployment
is completed, management of mailboxes and public folders is usually the
extent to which the Mailbox server is managed. When you install
Exchange, you need to consider a number of important things.
One of the biggest considerations is where Exchange should be installed and how the disks should be configured for the databases.
As best practice it is always good to have the operating system and the
system page file configured on separate RAID1 or RAID10 disks.
As with Exchange Server
2007, each database needs to be located on the same path on each server
that will host a copy. When deploying a DAG with more than 22 different
databases, managing drive letters might be a challenge. Rather than
assigning each drive a new letter, they should be assigned mount points
on a RAID-protected volume. Following this best practice will allow
more than 24 disks to be used and provide flexibility to remount a
replacement disks to that mount point quickly in case of a failure. If
the disk that hosts the mount points fails, the mount points will also
become unavailable. Protecting the mount point host volume with RAID
will ensure that a single disk failure will not cause all of the
databases to go offline.
This chapter has covered a
number of the storage improvements that have been made in Exchange
Server 2010. These changes affect all aspects of design and should
cause experienced Exchange administrators to reconsider a lot of the
accepted assumptions that have become rote. One of these is the need to
ensure that the transaction
logs and the database must be on separate physical disks. With the
lower I/O requirements and database write smoothing, this no longer
becomes a problem with disk contention. There are still reasons that it
might be good to split the transaction
logs and databases on separate volumes or disks. One such reason is to
not allow growing transaction logs to run the disk out of space and
cause the database to go offline. In a stand-alone deployment it is
still important to store the transaction logs on separate disks from
the database so that in the event of a disk failure, both the
transaction logs and the database are not lost. In a high-availability
deployment, multiple copies of the data already exist on other servers.
|
Thierry Demorre
Senior Director, Infrastructure Services Line, East Operating Unit, Avanade Inc.
Placing Exchange database
files and transaction logs on disk has always been a subject of
discussion between Exchange design engineers and the storage engineers.
Usually the former wanted to split those files across different
physical disks while the latter preferred a single large aggregate and
lay out all of those files together. Exchange Server 2010 provides a
simple solution to this design argument thanks to two major
improvements over previous Exchange versions: DAGs and a new I/O
profile.
Database Availability Groups
Three or more copies of a database
means more redundancy than in a typical RAID 1 or RAID 5 configuration,
which is enough redundancy for your database and transaction
log files. In the event of a failure of one of the instances, the
remaining data is not affected. Therefore, having the database and
transaction log files sharing the same physical disks should not be a
concern.
Extensible Storage Engine (ESE) I/O Profile
The ESE went through a major
overhaul in the way it handles disk writes. All of the previous
versions of Exchange have always written small, random blocks of data.
Now, ESE has been optimized for large sequential writes, which from a
disk activity perspective translates to most database writes being
sequential. Because transaction log writes are also sequential, mixing
those two I/O profiles on the same physical disks will not affect the
scaling capability.
|
1. Determining the Number of Mailboxes for Each Server
A number of factors go into deciding the number and size of mailboxes that should be placed on a single server and how to configure the number
of mailboxes that should be placed in each database. The final decision
will weigh several key factors, such as the size, relative importance,
and, most important, the service level agreement (SLA) required for the
mailboxes.
Although 10,000
mailboxes provided to university students with a maximum quota size of
25 MB at no cost may take up more space than 250 executives with a
maximum quota of 10 GB, the former mailboxes are arguably far less
important. Weigh this relative importance against the number
of mailboxes that can be recovered within the SLA. When it comes down
to it, database size is often governed by your redundancy design.
In both of these areas improvements have been made to reduce the need
and improve the speed of recovery should it be required. With these
changes and careful planning it usually is possible to increase the
size that the databases should be allowed to grow.
|
Thierry Demorre
Senior Director, Infrastructure Services Line, Avanade Inc.
Two of the most
common questions about Exchange are "How many mailboxes can I fit on
this server?" and "With this new version of Exchange, will we get twice
as many mailboxes on a server than in the previous version?"
Unfortunately, these questions have no definitive answers, because of a
number of contributing factors to both the performance and the space
requirements for an Exchange mailbox server. These are the two
principle factors to take into consideration for appropriately sizing
an Exchange Mailbox server.
Actually, asking how many
mailboxes can be hosted on a server is not the correct question. A
better way to approach the question would be to ask, "How many 1-GB
mailboxes, with a medium profile usage, having a 90 KB average message
size, with single item recovery configured for 20 days and calendar
versioning can I host on my server with 16 cores that run at 3.4G Hz
and have 32 GB of RAM and are connected to 48, 1-TB-large form factor
10,000 RPM SAS hard drives?" Although the qualification statement is
wordy, it does properly identify the target usage for the mailboxes.
Having this level of detail when asking this question will provide a
better basis for answering the question using the right tools.
The best practice here really
is two-fold: first you need to understand what you are sizing for, and
second you need to validate your assumptions against the Mailbox Server
Role Requirements Calculator published by the Exchange product group.
To do the former you must investigate the current environment and
profile the users that will be migrated or transitioned to the new
environment. To do the latter you should download and learn to use the
calculator. The calculator takes extensive testing done by the product
group and wraps it into a fairly simple Microsoft Office Excel
spreadsheet. This calculator should be the starting point at any
serious Exchange design. After gauging the configuration sizing using
the calculator you should use the information you have gathered to
configure tools such as JetStress and Load Simulator to prove the
calculations are correct.
After verifying the number
of mailboxes that can be hosted on the configured servers, the last
question that needs to be answered is how many is too many? As the
number of mailboxes on a server grows, the number of users that would
be affected in the event of a single server outage or degradation of
service increases. Employing high-availability best practices can curb
many of these problems; however, there is still risk in placing too
many mailboxes on a single server rather than scaling out the same
number of users across multiple servers.
|
2. Determining Where to Host Mailboxes
A number
of best practices are defined for placing mailbox servers and mailboxes
on these servers. As you define the location of each of your user
populations, the network connectivity, server and storage capabilities,
and skill sets available at each site, where to place the servers may
become clearer.
Several configurations are
used to define the configuration, as seen in the example solutions used
in this book. The Litware deployment is a distributed environment with
Exchange mailbox and other services pushed out to the remote sites.
This has several advantages, especially if the users at the remote
offices primarily communicate with each other. Because users primarily
communicate with each other, the majority of the e-mail messages stay
within the site and do not need to traverse the network. The side
benefit of this is that in the event of network issues where the remote
site loses connectivity back to one of the corporate sites, the local
users can continue to send and receive e-mail. The downside of this
configuration is that support for the remote servers can be challenging
especially if physical access is needed to repair the hardware.
The Fabrikam deployment uses a more centralized deployment. The benefit of this type of deployment is that mailbox
services are concentrated in locations that have appropriate network
connectivity and support staff to handle monitoring and maintenance of
the hardware and software.
The best practice for
determining where to host mailboxes depends on what fits the business
requirements, network requirements, and administrative requirements.
The principle should always be to keep the design as simple as possible
while still achieving the goals. You need to ask several key questions
when determining where to host mailboxes:
Is there adequate and redundant bandwidth available between the clients and the Exchange servers?
If
the Exchange servers will be hosted at a remote location, how will
backups, hardware maintenance, and monitoring be accomplished?
Does the remote site have adequate power, cooling, and network connectivity?
